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EXPANSION BRIDGE APPARATUS AND METHOD 
FORANI 2 C BUS 

FIELD OF THE INVENTION 

The present invention relates generally to electronic equipment that 
communicates using the industry standard I 2 C (inter-IC control) bus. More particularly, 
the invention relates to an expansion device for use in connection with such a bus. 

BACKGROUND OF THE INVENTION 

5 The use of I 2 C (inter-IC control) devices is very popular among designers of 

electronic systems because the devices offer an inexpensive way to provide distributed 
monitoring or control of a piece of equipment using a simple two wire serial 
communication bus. Inexpensive I C devices are available to monitor voltage, 
temperature, and other physical quantities, provide non- volatile memory, parallel IO 

10 ports, and a large variety of other specialized functions. These devices are widely used in 
many types of electronic equipment from consumer electronics to computer systems. 

An I 2 C bus provides for 128 unique addresses by definition. Real world designs, 
however, typically contain I C devices that use multiple I C addresses resulting in a 
practical limit of closer to 1-8 devices. Since only relatively few devices can be uniquely 

15 addressed on any given two wire I C bus, designers typically use multiple I C busses 
when the addresses on a given bus are used up. The use of multiple busses increases 
system cost and complexity. Another shortcoming of the I 2 C bus is that it does not 
provide any features to guarantee the integrity of the data that's traveling on the bus. 
Accordingly, there is a need for an I 2 C -type bus that practically supports a greater 

20 number of addresses while also providing an amount of integrity for data traveling 
thereon. 

SUMMARY OF THE INVENTION 

The present invention is an I 2 C (inter-IC control) bridge device which implements 
a communication protocol layered on top of a standard I 2 C protocol. The layered 
25 protocol used by the bridge device is termed the "Layered I 2 C Protocol" - abbreviated 
"LIP". Thus the bridge device is called a "LIP bridge device". The LIP bridge device 
provides I 2 C address extension, data integrity checking, and fault detection and isolation 
when inserted between an I C bus master and it's intended target I C device. Each LIP 
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bridge device has at least two attached I 2 C busses - a parent bus and a child bus. The LIP 
bridge operates as a slave on its parent bus, and a master of its child bus. The Layered 
I 2 C protocol is specified to operate on a bus between one or more bus masters and the 
parent bus of one or more LIP bridge devices. The child bus is used for attaching 
5 multiple I 2 C devices and/or one or more LIP bridge devices. 

In an exemplary implementation, the LIP bridge device is constructed using a 
microcontroller to create a LIP bridge device with one parent and one child I C bus port 
and a group of LIP bridge configuration pins. The parent bus traffic to a given LIP 
bridge device consists entirely of LIP packets, and the child bus traffic consists of 
10 standard I 2 C packets to communicate with standard child bus I 2 C devices. The child bus 
traffic may also consist of LIP packets to communicate with LIP bridges attached to the 
child bus. By design, the LIP packets and standard I 2 C transactions do not interfere with 

O one another. The LIP bridge device interprets LIP command packets from a bus master 

and translates them into the intended I C data stream that is then broadcast over the child 

^ 15 bus. Likewise, data from the child bus is used to create LIP packets that are returned to 

O the proper bus master. 

£? The use of LIP packets on a given I C bus provides an extra level of I C 

addressing. An I 2 C bus provides for 128 unique addresses by definition. In many cases, 
real world designs, however, typically contain I 2 C devices that use multiple I 2 C addresses 
^ 20 resulting in a practical limit of closer to 1-8 devices. By contrast each LIP bridge device 
O uses only one I 2 C address and provides a child bus with 128 free addresses. Therefore 

w LIP bridges expand the number of available addresses on the I 2 C bus from 128, to instead 

128 multiplied by the number of LIP bridge devices, which is a maximum of 
128x128=16384 1 2 C addresses. 
25 In one exemplary embodiment of the invention a first transceiver is coupled to a 

host bus master over a parent bus, where the host bus master uses a first communications 
protocol. A second transceiver is coupled to target devices over a child bus, the target 
devices utilizing a second communications protocol. The first protocol has a bridge 
device address field for addressing the bridge devices and a target device address field for 
30 addressing the target devices coupled to the child bus. The number of target devices 
addressable by the host bus master is expandable based on the number of bridge device 
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coupled thereto. A protocol translator is coupled to the first and second transceiver for 
translating communications in the first protocol destined for the target devices to the 
second protocol and translating communications in the second protocol destined for the 
bus master to the first protocol. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present invention may be obtained from 
consideration of the following detailed description of the invention in conjunction with 
the drawing, with like elements referenced with like references, in which: 
10 FIG. 1 is a block diagram for one application of the present invention I 2 C bridge 

device; 

FIG. 2 is functional block diagram for one embodiment of the present invention 
I 2 C bridge device; 

FIG. 3 is a block diagram for another application of the present invention I 2 C 
15 bridge device; 

FIG. 4 illustrates the basic command structure for a command from the host bus 
master to the LIP bridge; 

FIG. 5 shows a detailed illustration of the LIP address hardware strapping; 

FIG. 6 shows a detailed illustration of the LIP address byte; 
20 FIG. 7 shows a detailed illustration of the child address/function byte; 

FIG. 8 shows a detailed illustration of the read count field byte; 

FIG. 9 shows a detailed illustration of the read data tag byte; 

FIG. 10 shows a detailed illustration for an exemplary embodiment of the status 
byte register; 

25 FIGS. 11-16 show exemplary transaction structures for selected commands 

generated from the host bus master to LIP; 

FIGS. 17-18 show pinouts for exemplary microcontrollers used to implement the 
present invention I C bridge device; 

FIGS. 19-21 show exemplary data flows for various levels of firmware used in 
30 connection with the I 2 C bridge; and 



3 




Delmonico-1 



FIG. 22 shows an exemplary embodiment for an expansion bridge using an 
alternate parent bus. 

DETAILED DESCRIPTION 

The present invention is an I 2 C (inter-IC control) bridge device which implements 
5 a communication protocol layered on top of a standard I 2 C protocol. The layered 
protocol used by the bridge device is termed the "Layered I 2 C Protocol" - abbreviated 
"LIP". Thus the bridge device is called a "LIP bridge device". The LIP bridge device 
provides I 2 C address extension, data integrity checking, and fault detection and isolation 
when inserted between an I C bus master and it's intended target I C device. Referring to 
10 Fig. 1, an illustration of a typical usage of the LIP bridge device 10 is shown. Each LIP 
bridge device has at least two attached I 2 C busses - a parent bus 12 and a child bus 14. 
The LIP bridge device 10 can have more than one child bus or parent bus port. The LIP 
O bridge 10 operates as a slave on its parent bus 12, and a master of its child bus 14. The 

|S Layered I 2 C protocol is specified to operate on a bus between one or more bus masters 16 

J1 15 and the parent bus of one or more LIP bridge devices. The child bus 14 is used for 
O attaching multiple I 2 C devices 18 and/or one or more LIP bridge devices 10. As shown, 

u the LIP bridge devices can also be cascaded. 

;L In an exemplary implementation, the LIP bridge device 10 is constructed using a 

y 2 

yjj microcontroller to create a LIP bridge device with one parent and one child I C bus port 

[f* 20 and a group of LIP bridge configuration pins. The parent bus traffic to a given LIP 
5 bridge device consists entirely of LIP packets, and the child bus traffic consists of 

standard I 2 C packets to communicate with standard child bus I 2 C devices. As will be 
explained, the child bus traffic may also consist of LIP packets to communicate with LIP 
bridges attached to the child bus. By design, the LIP packets and standard I 2 C 
25 transactions do not interfere with one another. The LIP bridge device interprets LIP 

command packets from a bus master and translates them into the intended I 2 C data stream 
that is then broadcast over the child bus. Likewise, data from the child bus is used to 
create LIP packets that are returned to the proper bus master. 

The use of LIP packets on a given I C bus provides an extra level of I C 
30 addressing. An I 2 C bus provides for 128 unique addresses by definition. In many cases, 
real world designs, however, typically contain I 2 C devices that use multiple I 2 C addresses 
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resulting in a practical limit of closer to 1-8 devices. By contrast each LIP bridge device 
uses only one I 2 C address and provides a child bus with 128 free addresses. Therefore 
LIP bridges expand the number of available addresses on the I 2 C bus from 128, to instead 
128 multiplied by the number of LIP bridge devices, which is a maximum of 
128x128=16384 1 2 C addresses. 

/xteferring to Fig. 2, a high lefvel functional block diagram of a LIP bridge 
T device 10 is shown. The bridge device 10 couples to the LIP bus 12 via an LIP bus 
Wansceiver 20. This I 2 C transceiver is an I 2 C slave only, and responds to LIP packets 
addressed to the LIP bridge from a Host I 2 C Bus Master 16 (Fig. 1). The I 2 C bus master 
10 is typically an intelligent deyice, e.g., a microprocessor, that is responsible for gathering 
data and providing control/via the commands issued and received o the LIP bus. The I C 
transceiver 20 can also function as a slave transmitter so that the Host I 2 C Bus Master 16 
can extract data from the LIP bridge 10. In the incoming direction the bus transceiver 20 
couples to a CRC (cyclical redundancy check) generator and checker 22 which calculates 
15 a CRC code for any mcoming or outgoing LIP packets. As is well known, a CRC code is 
a unique number that is related to the data in a mathematical way such that even a single 
bit change in the data will result in a different CRC code. 

A bridge read engine 24 is activated by the LIP bus I 2 C transceiver 20 when a 
Host I 2 C Bus Master 16 wishes to extract data from the LIP bridge 10. If data is 
20 available it is tagged with information to identify the intended receiver, the data, and 
length. This is followed by a CRC check code so that the Host I 2 C Bus Master 16 can 
verify that the data was not corrupted during transmission. If no data is available, the 
bridge read engine generates a packet signifying to the Host I 2 C Bus Master 16 that there 
was no data available. Outgoing LIP packet FIFOs 28, 29 accumulate data from requests 
25 made to the LIP bridge 10 until the requesting Host I 2 C Bus Master 16 reads the data 
from the LIP bridge. There can be one or more such FIFOs, e.g., one for each Host I 2 C 
Bus Master. Although only one host bus master is required, additional benefits may be 
realized in system configurations including two or more I 2 C Bus Masters. In such 
configurations, data tagging and the ability to recover data obtained but transmitted 
30 unsuccessfully due to, for example, multi-master interference, become valuable. 
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An incoming LIP packet FIFO 30 accumulates incoming LIP packets for 
processing by a LIP packet parser and dispatch function 32. The LIP packet parser and 
dispatch mechanism 32 removes LIP packets from the Incoming LIP Packet FIFO 30, 
and verifies that the packet passed the CRC check. It then verifies the packet contents are 

5 a valid command and verifies that the entire packet was received within a specified time 
window. If all tests pass, then the command is forwarded to a command engine 36 or 52 
for processing. If any tests fail, the packet is discarded and an error logged. Data from 
the LIP packet parser and dispatch is provided to a command collision detection unit 38 . 
The command collision detection unit 38 determines if multiple Host I C Bus 

10 Masters 16 have pending commands that will result in the potential for a given master 
receiving the wrong data. In this case, a special packet is returned for all Host I 2 C Bus 
Master reads until the collision condition is clear. The packet informs all involved Host 
I 2 C Bus Masters 16 that their data is available, and can be obtained via a retry. An error 
logger 40 receives error signals from all relevant functional units, and writes the data in a 

15 standard format to an internal error log 41 . Error data is preserved until it is read out by a 
Host I C Bus Master, then explicitly cleared. A LIP bridge global reset unit 42 is 



r; responsible for resetting the entire state of the LIP bridge device 10 when requested. It 

=_ can also render the bridge inoperative and tri-state all outputs - in case the LIP bridge has 

j\ an internal failure and must be isolated so that a partner LIP bridge can function in its 

20 place. The LIP bridge global reset unit 42 receives inputs from three sources: a global 
Q watchdog timer 44, a LIP supply voltage monitor 46, and an incoming partner reset-in 

" signal line 48. All three of these sources can cause a reset of the LIP bridge 10. In 

addition, if the partner reset-in signal line 48 is held asserted, it will render the LIP bridge 
inoperative and electrically inert by tri-stating all outputs. 

The global watchdog timer^ signals the LIP bridge global reset unit 42 if any 
bnal unit within the LIP bridge fails to check in at a regular interval. This allows 

recovery from transient errors. The LIP supply voltage monitor 46 will signal 

/ 

the LIP bridge global reset unit 42 if the power supplied to the LIP bridge falls below a 
certain threshold. An even/watchdog timer 48 is used by several functional units to time 
30 a given operation. 
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A child bus I 2 C transceiver 50 functions as an I 2 C master only on the child bus 14. 
It sends data to and receives data from I 2 C targets 18 attached to the child bus in response 
to commands from the child bus command engine 36. The child bus command engine 36 
receives commands from the LIP packet parser and dispatch unit 32 to send data to or 
5 extract data from a given child bus I 2 C target and relays the request to the child bus I 2 C 
transceiver 50. In the case of a child bus read operation, all data received is placed into 
the respective outgoing LIP Packet FIFO 28, 29. If the read was unsuccessful according 
to the child bus I C transceiver 50, then a formatted error packet is placed into the 
appropriate outgoing LIP packet FIFO 28, 29. A special function command engine 
10 receives commands from the LIP packet parser and dispatch unit 32. An extensive list of 
commands exists to retry operations, read and clear error log entries, query the status of 
the LIP bridge, perform internal tests, and modify operational characteristics of the LIP 
bridge. Some of these commands place data into an appropriate outgoing LIP Packet 
FIFO 28, 29. 

15 LIP Protocol 

A unique protocol is utilized in accordance with the present invention between a 
host bus master, the PC busses to which the host bus masters is connected, and target LIP 
bridges. The LIP bridges are the target of the messages from the host bus master. The 
host bus master and LIP bridges utilize LIP to communicate. LIP bridges provide 

20 electrical PC isolation, PC address extension, and data integrity enhancement. The 
electrical isolation that LIP bridges supply between the host bus master busses and the 
actual child PC busses enhances overall reliability of a system. 

As mentioned, the LIP bridge supports a slave-only parent bus and a master-only 
child bus. In an exemplary embodiment, the parent bus is handled by high performance 

25 dedicated PC hardware within the LIP bridge microcontroller, and child bus 

communication is done using a firmware PC driver with hardware assistance from the 
LIP bridge microcontroller. Alternately, communication on both busses could be 
implemented utilizing high performance hardware, or for lower cost and performance 
communication on both busses can be implemented predominately in firmware. 

30 In another exemplary application of the present invention shown in Fig. 3, the 

host bus master 1 16 is the PC master of A and B busses 1 12, 1 13, where two busses are 
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utilized to provide increased data integrity. These busses make use of LIP messages, 
where each of these busses is connected to one or more LIP bridges 1 10 which act as PC 
slaves. Each LIP bridge 110 has a unique programmable PC address selected by pin 
strapping on the LIP bridge device. Every LIP bridge is the PC master of the single child 
bus 1 14 to which it is connected. One or more PC devices 1 1 8 are attached to the child 
bus 1 14, and standard PC protocol is used to communicate to them. Bridge cross resets 
are used to enhance reliability by allowing each LIP bridge to reset and/or tri-state the 
other bridge 

An understanding of PC communication is helpful to understanding the Layered 
PC Protocol, since LIP is layered on standard PC protocol. A description of the I2C 
protocol is included in "The I 2 C-Bus Specification" Version 2.0, December 1998, Philips 
Semiconductor, Version 2.1, January 2000 and "The I 2 C-bus and how to use it" April 
1995, Philips Semiconductor, which are available at 

http://vmw-us2.semiconductors.philips.com/acrobat/various/I2C BUS SPECIFICATION 2.pdf . 

the entire content of the documents being incorporated by reference herein. 

All communication between a host bus master 116 and a LIP bridge 110 takes 
place using the Layered PC Protocol. Although LIP communication is bi-directional, the 
host bus master is always master and initiates all communication with the LIP bridge. 
Thus the host bus master 1 16 (in a manner similar to traditional I 2 C protocol) provides 
serial clock and data signals when transmitting to the LIP bridge (master transmitter), and 
(as master receiver) a clock for receiving messages from the LIP bridge. The LIP bridge 
therefore functions as an PC slave when receiving data or slave transmitter when 
returning data to a host bus master. Thus, it is understood that the parent bus has the 
same operational characteristics as that of the standard PC two wire bus. 

Writing data from the PC master (always the host bus master) to the PC slave 
(always the LIP bridge) is initiated and carried to completion by the PC master. 
Typically, the master asserts an PC start on the bus, followed by a slave address with the 
write bit set. If the slave acknowledges receipt of the address, then the master can send 
one or more data bytes to the slave. Reception of each data byte must be acknowledged 
by the slave. A successful transaction is complete when the master asserts an PC stop on 
the PC bus. 
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When the master (host bus master) needs to read data from the slave (LIP bridge), 
the host bus master first writes a command to the LIP bridge to request the desired type 
and quantity of data the host bus master wishes to read. The master can then begin the 
read transaction. The read is initiated with an PC start, followed by the slave (LIP 
5 bridge) address with the read bit set. After the LIP bridge slave acknowledges the 
[address + 'R'] byte, the host bus master is designated a master-receiver, and the LIP 
bridge slave becomes a slave-transmitter. The master then clocks data out of the slave a 
byte at a time, until the slave has supplied the number of bytes requested by the master. 
After the master receives each byte, the master must provide an acknowledge bit to the 
10 slave on the ninth clock pulse. This is normally done automatically by the host bus 
master's hardware PC transceiver. The transaction is completed when the master 
purposely signals a no-acknowledge for the last data byte it receives, and then asserts an 
PC stop condition on the bus. 

"In the exemplary embodiment o/the invention, a master write command from the 



% - $j( ^ us master t0 the LIP bridge ha^d four byte format 120 as shown in Fig. 4. Each 
equest to the LIP bridge will consist of exactly four bytes. A LIP Address 122, a Child 
address / Function field 124, followed by one byte (data to write or a count field for 
reads) 126, and finally a CRC 128 for the packet. 

Every packet sent to the LIP bridge must be four bytes in length. Packets which 
20 are not exactly four bytes in length are discarded, and an error is logged. The LIP bridge 
marks the end of a packet by sensing a start or stop on the PC bus. The packet is 
discarded and an error is logged if a packet is shorter than four bytes and is not completed 
within a time out period or if a new packet is sent before the previous packet is complete. 
The LIP bridge can return from one to fifteen bytes of data to the host bus master 
25 during a read operation plus one additional byte which is the CRC byte for the data read. 
If the master continues to read data past the number of bytes requested in the read count 
field (plus one more byte of CRC), then the LIP bridge will return the extra bytes as valid 
CRC values. If the master terminates the read transaction (by no-acknowledging a byte) 
before 'read count' bytes (plus the CRC byte) are read, then an "UNREAD_DISC" error 
30 will be logged and the remaining data will be discarded. Once the host bus master begins 
reading data from the LIP bridge, the host bus master has a fixed time period to clock all 
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the data for the read transaction out of the LIP bridge. After the fixed time period, an 
"SLV_XMT_TIMEOUT" error will be logged, and the remaining data will be 
discarded. 

Each LIP bridge responds to a unique PC address configured by strapping pins on 
5 the LIP bridge device. As will be explained herein, an exemplary bridge device will 
typically be incorporated within the context of a microcontroller. Other possible 
embodiments could include incorporation an ASIC. Moreover, the hardware requirement 
is small enough that the LIP bridge could occupy a reasonably small portion of a large 
system ASIC. Alternately, the LIP bridge could use a small fraction of the resources of a 

10 system's main processor (such as in a personal computer or an industrial controller). 
The hardware address strapping 130 will be assigned as shown in Fig. 5. The LIP 
address byte 122 (Fig. 6) identifies which LIP bridge the command packet is destined, 
and whether the packet describes a read or a write command. Thus there are seven bits 
available for addressing LIP bridges. The PC protocol does not allow for address data 

15 protection on the bus. However, transmitted addresses are protected by the packet CRC. 
If the address field of the packet is corrupted, and that causes it to arrive at the wrong LIP 
bridge, then the LIP bridge accepting the packet will ignore the packet and log an error 
due to an invalid packet CRC. The LIP bridge device will have seven pins available for 
address strapping (plus one address parity pin to make odd parity), allowing up to 128 

20 LIP bridges per bus. The strapping pins A0-A6 will correspond to bits 1-7 respectively in 
the LIP address 122 (see Fig. 6). On the parent bus during transactions, bit 0 is a 
Read/Write function bit pertaining to the LIP bridge addresses, in accordance with 
standard I 2 C protocol. In one exemplary embodiment, the LIP bridge will not function if 
the address strapping does not produce odd parity. This parity protection will normally 

25 prevent LIP bridge address contention on the LIP bus. Should multiple strapping errors 
defeat this mechanism, then the CRC protection on each packet will prevent data 
corruption in case two LIP bridges are responding to the same address. Ultimately, the 
CRC protection will allow the host bus master to detect the contention fault. 

Referring to Fig. 7, it can be seen that the Child Address / Function byte 124 can 

30 be used for one of two purposes. As a child bus address, this byte can be used to cause an 
address cycle on the child bus to begin a read or write transaction to a target on the child 
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bus. All transactions on the child bus begin with an PC start followed by a child address. 
Because of the variety of target PC devices and resulting transactions, the PC child 
address may be followed by reading or writing to the target. The type of transaction 
(read or write) is determined by bit zero of the child address. The number of bytes 
5 written to or read from a child bus PC target may vary depending on the target device and 
the transaction type. 

Secondly, if the Child Address field 124 is specified as binary '1111. Ill x' (OxFF 
or OxFE), then the entire packet is interpreted as a special function. Special functions are 
used to query the LIP bridge or perform specific LIP bridge operations. In the 

10 embodiment of Fig. 4, the low bit is used to identify the host bus master that is requesting 
the special function command. If the low bit is '0' the command is being requested by 
host bus masterO, and if the bit is ' V the command is requested by host bus masterl . The 
value of this bit is set by the requesting host bus master, passed through the LIP bridge, 
and returned in a "Read Data Tag" byte 132 (Fig. 9) if appropriate. For special function 

15 commands that return data to the host bus master, this allows the requesting host bus 

master to verify that the data it is reading is actually intended for it. The use of this bit by 
the host bus master is equivalent to the "Srcld" field of the Read Count byte sent during 
child bus read commands. (See Fig. 8.) 

Still referring to Fig. 7, the Child Address field 124 specifies whether the child 

20 will be written to or read from. If the transaction is a 'write' then the "write data" field 
126 is the data written to the child. The LIP bridge does not interpret this data - it is 
simply passed through. It is up to the master to issue the proper number of data bytes in 
the correct sequence to perform a desired operation on the child bus PC target. 

The host bus master can perform single byte writes to an PC target on the child 

25 bus by sending one packet to the LIP bridge. The four-byte packet will contain the child 
address 124 and the write data 126. If a multiple byte write is not currently in progress, 
the LIP bridge will initiate an PC start on the child bus, transmit the child address and 
write data, and issue a stop on the PC child bus. Single byte writes are useful for simple 
devices such as byte wide PC 10 expanders. 

30 Some PC targets on the child bus require multiple bytes of data from the host bus 

master to perform common operations. The LIP bridge supports writing multiple bytes to 
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a child bus target as follows. The host bus master must: 1) issue the "CHILD_ I2C 
JSTART" special function command to directly cause an PC start on the child bus; 2) 
issue the desired number of single byte write packets to the intended child bus target; 
since an PC start was explicitly forced by host bus master, these write packets do not 
5 generate start cycles on the child bus, and only the first packet causes an address to be 
sent out on the child bus and 3) issue the "CHILD_ I2C JSTOP" special function 
command to directly cause an PC stop on the child bus, or issue a write with a child 
address field different from the first data packet. 

If not explicitly requested by the host bus master, a stop will automatically be 
10 issued on the child bus by the LIP bridge if during a multiple byte write the LIP bridge 
receives a packet from host bus master with a different child bus target PC address field. 
As shown in Fig. 8, if the transaction is a child bus read, then the second byte 126 
□ is a count field which specifies how many bytes the host bus master wishes to receive. 

m This count field can specify from one to fifteen bytes inclusive. A count of zero or 

~i 15 greater than 15 will cause the command to be ignored, and an error will be logged. The 
O "RdCnt" field is six bits wide to allow for a possible future increase in read packet 

y[ lengths. The "Srcld" field is a one-bit identification tag that the LIP bridge returns to the 

L, host bus master when the host bus master ultimately reads the child bus data. When 

5 S 

43 submitting a child bus read request, host bus masterO should clear this bit, and host bus 

20 master 1 should set this bit to ' V . 
D Referring to Fig. 9, it is illustrated that during a LIP bridge read by the host bus 

™ master, the LIP bridge returns a "Read Data Tag" byte 132 to the host bus master before 

actual data is returned. This is done to help a given host bus master verify that the 
incoming data belongs to it, is the quantity expected, and is valid data. The data 
25 indicated by reference numeral 130 is returned to the host bus master as a response to the 
LIP bridge read. The "Read Data Tag" byte consists of three fields. The RdCnt field 134 
is the amount of data the LIP bridge is ready to return to the host bus master. This 
amount may differ from the "RdCnt" amount requested in the original child bus read 
command. The Srcld field value 136 comes from the original host bus master child bus 
30 read (or special function command) request and is '0' for host bus masterO, and ' V for 
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host bus masterl . The NoData field 1 38 indicates if there is data available for the LIP 
bridge read. 



Table 1- summarizes how to interpret the "Read Data Tag" byte. 



NoData 


Srcld 


RdCnt 


Interpretation (and recovery) 


1 


X 


0 


The LIP bridge is responding to a LIP bridge read that 
was not expected, or potentially, the original request for 
the data was corrupt so that no data is available for a LIP 
bridge read. The entire transaction should be retried. 


1 


X 


NonO 


The LIP bridge was unable to obtain data from the Child bus for the 
host bus master's read request due to a child bus error. The SMC can 
check the LIP bridge status byte to determine if there was a child bus 
error or a LIP protocol violation. The entire transaction should be 
retried. 


0 


X 


1-15 


The LIP bridge obtained RdCnt bytes for the host bus master's child 
bus read request. The bytes can be read from the LIP bridge along 
with the CRC. Data will be available for the 
"R_LAST_CHILD_DATA_x" command should the SMC need to 
retry the LIP bridge read. 

If the SMC detects that the SrcID field is incorrect, then it has 
accidentally snatched the other host bus master's data. The correct 
data can likely be obtained by issuing the appropriate 
"R_LAST_CHILD_DATA_x" command. If that command results 
in a "no-data" return from the LIP bridge, the entire transaction 
should be retried. 


0 


X 


0 


The LIP bridge is responding to a LIP bridge read during a multiple 
SMC read command collision. "RdCnt" field of zero indicates that 
all data read by SMC for this transaction will be random (invalid) 
with a valid CRC. The data can be recovered with the appropriate 
"R_LAST_CHILD_DATA_x" cmd, after a staggered timed back 
off to avoid another conflict. 



The child bus read command is sent by the host bus master to define the type and 
quantity of data the host bus master wishes to receive from the LIP bridge. Although all 
commands sent to the LIP bridge from the host bus master are a fixed length of four 
bytes, the quantity of data returned to the host bus master during a LIP bridge read is the 
quantity the host bus master reads out based on the read request - and can thus vary. To 
receive the data the host bus master must begin a new transaction on the LIP bus which 
consists of an PC start, followed by the LIP address byte with the R/! W bit set (to 
indicate a read operation). The host bus master can then read the data it previously 
requested from the LIP bridge. The return data will consist of a "Read Data Tag" byte 
132, followed by the amount of data 140 specified in the RdCnt field 134 of the "Read 
Data Tag" byte, plus one CRC byte 142. 
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There is a subset of commands that can not be issued between the child bus read 
command (or special function command prefixed by "R_") sent to the LIP bridge and the 
actual reading of the data (via a LIP bridge read). This restricted subset includes all 
commands in Table 1 prefixed by "R_", and child bus read requests. The set of safe 
5 commands that can be issued during a pending child bus read request include child bus 
write requests and various LIP bridge maintenance commands. Issuing any one of the 
restricted commands has a different effect depending on the source requester. A host bus 
master may also be referred to as a system master controller (SMC). 

Table 2 



Command N 


Command N+l 


Result 


SMCx: 

Child bus read or 
special function 
command 
prefixed by "R_". 


SMCx: 

child bus read or special 
function command 
prefixed by "RJ\ 


The data for Command N is discarded in favor of the 
data for command N+l . A SNG_RD_CNFLT error is 
logged. The next LIP bridge read will return data for 
command N+l. 


SMCx: 

Child bus read or 
special function 
command prefixed 
by "RJ\ 


SMCy: 

child bus read or special 
function command 
prefixed by "R_". 


Commands N and N+l are both honored and executed. 
No error is logged for the collision. When SMCx and 
SMCy perform a LIP bridge read to extract their data: 

1. The reads are treated as unexpected returning a 
"Read Data Tag" of *0\ The data stream returned 
will consist of a random seed followed by a stream 
of bytes for which the last byte will be valid CRC 
for die previous bytes. 

2. SMCx and SMCy must perform a timed back off 
to ensure no new child bus read or special function 
command prefixed by "R_" is performed until all 
outstanding data is fully recovered. 

3 . SMCx and SMCy can recover their requested data 
by executing a RJLST_CHILD_DATA_IDn 
command, so long as no new commands overwrite 
the data. If the data is overwritten, an 
"UNREAD_DISC" error is logged. 



10 

Beginning with the "Read Data Tag" byte and followed by all bytes from the 
target child PC device, the LIP bridge will accumulate a CRC for the read transfer. The 
CRC is accumulated for the total number of bytes requested in the read command or for 
15 as many bytes as the child bus transfer continues, in case the child bus transfer is aborted 
before completion. 



14 




Delmonico-1 



In a similar fashion the LIP bridge will accumulate a CRC for the data requested 
by any special function command which returns data to the host bus master, including the 
"Read Data Tag" byte. The LIP bridge makes all calculated CRCs available for 
immediate transmission following the last data byte. The host bus master must read one 
byte beyond the last requested data byte to obtain the CRC. If the host bus master fails to 
read the CRC byte (by terminating the read transaction before clocking out the CRC) the 
LIP bridge will log an "UNREAD J)ISC" error. The CRC can be obtained until it is 
overwritten by a new CRC. 

In case a LIP bridge detects a hard fault on the child bus, any child bus read 
transaction will return the "Read Data Tag" byte indicating an error, followed by a stream 
of random data bytes to the host bus master (length equal to the length requested in the 
original read request), and a valid CRC byte. This behavior will insure that the host bus 
master detects an error condition. The LIP bridge will not retry the failed child bus read 
operation. 

Every four-byte packet to the LIP bridge concludes with a CRC byte. This byte is 
calculated on the first three bytes of the packet using a CRC algorithm. The LIP bridge 
verifies that the CRC sent by the host bus master matches the CRC it calculates for the 
received data. If a mismatch between the CRCs is detected, the packet is ignored, and a 
"BAD_CRC_IN" error is logged. 

The host bus master can detect a missing LIP bridge easily. LIP bridge presence 
detection is best done immediately following a LIP bridge or system reset event to avoid 
misinterpreting an input queue overflow condition as a missing LIP bridge. If the host 
bus master transmits a LIP address on the LIP bus and that address byte is followed by a 
no-acknowledge, then there is no LIP bridge responding to that LIP address. If the LIP 
address is followed by an acknowledge, then a LIP bridge is present and responding to 
that LIP address. 

The LIP bridge has an input queue for accepting packets from the host bus master. 
This queue has a limited depth. If the host bus master should fill the queue by 
transmitting packets faster than the LIP bridge can process them, then the LIP bridge will 
signal a queue full condition by no-acknowledging the LIP address and issuing no- 
acknowledge' s for each byte the host bus master sends after the LIP address. This no- 
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acknowledge signal will continue for all bytes the host bus master attempts to send to the 
LIP bridge until the LIP bridge has had time to clear some of the input queue. The LIP 
bridge will log an "input queue full" error. The host bus master can continue re-sending 
the packet's bytes after a short delay. 
5 The LIP bridge saves the data portion of the last master write packet received 

from the host bus master. The host bus master can read back this data if desired. If after 
receiving a packet the LIP bridge detects a CRC mismatch with the received CRC, the 
packet is ignored, and an error is logged. The host bus master can query the LIP bridge 
for the status and/or the last data sent to the LIP bridge if there is suspicion of a problem. 

10 LIP bus errors can be caused by momentary electrical disturbances from hot-plug 

events, or more serious problems such as failing hardware. The LIP bus is a two wire 
serial bus that electrically meets the PC electrical specifications. The simplicity of the 
PC low level protocol limits the number of errors that can happen on the bus to: 1) faults 
which cause one of the two bus wires to remain stuck at a logic level and 2) transient 

15 errors on the bus wires which corrupt a byte or address in transit on the bus. The errors in 
the first case are detectable by the host bus master. The LIP bridge functions as a slave to 
the host bus master and so can't reasonably detect such errors. Transient errors can affect 
both the host bus master and the LIP bridge. 

The LIP bridge and the protocol itself are designed to provide electrical isolation, 

20 address extension, and data integrity enhancement by bridging the LIP bus and the 

attached child bus. The LIP bridge has no knowledge of the purpose of the data passed 
through it, and therefore the LIP bridge is incapable of detecting errors that involve more 
than one packet. The LIP bridge can only detect errors within a single master write 
packet from host bus master. When the host bus master is reading data from the LIP 

25 bridge (with the LIP bridge functioning as a slave transmitter) the host bus master will be 
able to detect LIP bus errors using the CRC supplied by the LIP bridge. Table 3 below 
lists high level LIP bus errors and recovery actions. 



Table 3 



Error Type 


Error Outcome 


Recovery Action by host bus master 


host bus master write 
to LIP bridge with 
corrupted four-byte 
command packet. 


Packet CRC mismatch detected in LIP 
bridge, packet is ignored in LIP bridge, 
LIP bridge logs an error. 


host bus master ultimately discovers discrepancy 
via cross checking or via reading LIP bridge error 
log. host bus master either retries operation or uses 
data from other LIP bridge. 
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Portion of multi-byte 
host bus master write 
to LIP bridge 
corrupted. 


Packet CRC mismatch detected in LIP 
bridge, packet is ignored in LIP bridge, 
LIP bridge logs an error. 


After completing all master writes to LIP bridge 
associated with multi-byte child bus write, the host 
bus master reads the LIP bridge error log and notes 
one or more errors, host bus master must reissue 
multi-byte transaction. 


host bus master 
receives data from 
LIP bridge as slave 
transmitter, data 
stream is corrupted. 


/\s a siave uaiismiuer L,ir on age can i 
detect this type of error. 


upon receiving <ui uaia, hum oub iiiaMcr uciciuiinca 
via cross check or by checking CRC for received 
data that the data is corrupt, host bus master can 
issue R_LAST_CHILD_DATA command to 
recover data from a child bus target, or in the case 
of corrupt data from a special function command - 
reissue the command. 



Child Bus Arbitration 

The LIP bridge is the master of the child bus it is attached to. Because in the 
5 exemplary implementation of Fig. 4, there are two LIP bridges 1 1 0 connected to each 
child bus 114, they must arbitrate for the child bus when there is a need to communicate 
with a child bus target 118. The procedure for arbitration is defined in the PC 
specification and is used by the LIP bridge. Following the PC specification in this area 
guarantees there will be no PC contention on the child bus. If the two LIP bridges 

10 receive commands from the host bus master which require use of the child bus, then each 
LIP bridge will arbitrate for the bus, and one will win. When the bus is free following the 
completion of the child bus transaction, the LIP bridge which lost arbitration can try to 
arbitrate again. There is no priority in arbitration so each LIP bridge has an equal 
opportunity to win the arbitration. 

15 An interesting property of PC occurs when two LIP masters simultaneously start 

the exact same transaction on the same child bus to the same child bus target. In this case 
it is possible that the transaction will proceed on both LIP bridges in lockstep - with each 
LIP bridge thinking that it is the master for the transaction. Because of data and clock 
OR'ing, and the rules of data and clock toggling, this is perfectly allowable and will not 

20 degrade signal integrity or performance on the bus. It has the side benefit of guaranteeing 
that the host bus master will see identical data from the child bus since it was read only 
once from the source. 

Special Function Commands 

Special Function commands are used to cause the LIP bridge to perform a specific 
25 action or return to the host bus master requested data. Special functions are provided for 
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verification of data validity and other purposes. There are several different classes of 
special function commands. For example, special function commands include commands 
neither requiring nor returning data. These commands perform a simple action within the 
bridge or on the child bus. Also included are commands that return data to the host bus 
master on a subsequent master read of the LIP bridge. These commands typically 
provide LIP bridge internal information or status to the host bus master. In Table 4, these 
commands are prefixed by "R_". In addition, special function commands are commands 
that require data from the host bus master before being invoked. In Table 4, these 
commands are prefixed by "W_". 



Table 4 



Special Function 


Hex 
Command 
Code 


Comments 


Reserved 


0x00 


Reserved command 


RJ2C_ADDR 


0x01 


Returns one byte PC address that LIP bridge is strapped to in hardware. The 
host bus master can use this command to verify that it is communicating 
with the LIP bridge it attempted to address and there are no address 
collisions. 


RTEST_PATT 


0x03 


Returns test pattern of OxAA. The host bus master can use this command to 
verify access to the LIP bus. 


R_STATUS 


0x05 


Returns LIP status byte 


R_VERSION 


0x07 


Returns one byte LIP version number. This number should be used by host 
bus master to track LIP capabilities. 


RLIPERRLOG 


0x09 


Returns error log for LIP bus 


R_CHILD_ERRLOG 


OxOB 


Returns error log for child bus 


R_LAST_DATA_BYTE 


OxOD 


Return last "write data" field from command packet. Returns one byte - last 
data sent. 


R_LAST_CRC 


OxOF 


Return last calculated CRC. Returns one byte. 


R_DUMP_LIP_RAM 


0x11 


Returns all LIP memory bytes from address 0-191. This is for diagnostic or 
error logging purposes only. 


R_LST_CHILD_DATA__IDO 


0x13 


Return all data LIP bridge gathered from last child bus read command issued 
by source ID 0. 


R_LST_CHILD_D AT A_ID 1 


0x15 


Return all data LIP bridge gathered from last child bus read command issued 
by source ID 1. 


CLEAR_CHILD_ERRLOG 


0x02 


Rearm and clear error data from child bus error log. Also updates LIP status 
byte. 


CLEAR_LIPJERRLOG 


0x04 


Rearm and clear error data from LIP bus error log. 
Also updates LIP status byte. 


CHILDJ2C_START 


0x06 


Perform PC start on child bus. 
Used to initiate multi-byte write. 


CHILD_I2C_STOP 


0x08 


Perform PC stop on child bus. 
Used to end multi-byte write. 


ENABLE_BAD_CRC 


OxOA 


Cause all calculated CRC's returned to host bus master to be incorrect. 
Mode stays enabled for all transactions until mode is disabled again. This is 
for diagnostic purposes only. 


DISABLE_BADCRC 


OxOC 


Send correct CRC data to host bus master for all transactions. This is the 
power on / reset default. 


RESET_LIP_SELF 


OxOE 


Reset this LIP bridge. 


RESET_LIP_PARTNER 


0x10 


Reset partner LIP bridge. 
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HOLDRSTJLIP_PARTNER 


0x12 


Assert then hold partner LIP bridge in reset. The partner LIP bridge will be 
held in reset. Partner reset can be released by issuing a 
RESET_LIP_PARTNER command. This command is useful in case the 
host bus master suspects that the partner LIP bridge has gone bad, and needs 
to be held off the child PC and LIP busses. 


NOP 


0x14 


Does nothing. During transmission by the host bus master, the LIP bridge 
will acknowledge each byte of the packet. Upon successful reception of a 
valid NOP command, the command is ignored. No state within the LIP 

hridce is chanaed This command is intended to nrovide a method for the 

host bus master to detect that a LIP bridge is present, without the need to 
read data back from the LIP bridge (as with R_TEST_PATT, etc.). A 
BAD_CRC_IN error will be logged if the CRC is bad for NOP command 
packet. 


Reserved for future use. 


0x14,0x16, 
0xl7-xFF 





LIP Bridge Status Byte 

Referring to Fig. 10, the LIP bridge status byte 150 contains a one byte summary 
of the most important aspects of LIP bridge health. The host bus master has read only 
access to this status byte. Following any type of LIP bridge reset or power cycle, the 
value of all status bits within the byte is zero. Status Bit Descriptions are as follows: 
RAZ - "read as zero" indicates a bit reserved for future use that will return a zero if read. 
CBRE - Child Bus Read Error indicates the LIP bridge has detected and logged an error 
on its child bus during a read operation to a child bus target by the LIP bridge. The first 
error that occurs is logged and locked in the child bus error log. The details of the error 
can be obtained by issuing the "R_CHILD_ERRLOG" special function command. 
Issuing the "CLEAR_CHILD_ERRLOG" command will clear and rearm the error log, 
and also this status bit. CBWE - Child Bus Write Error. The LIP bridge has detected and 
logged an error on its child bus during a write operation by the LIP bridge to a child bus 
target. The first error that occurs is logged and locked in the child bus error log. The 
details of the error can be obtained by issuing the "RCHILDERRLOG" special 
function command. Issuing the "CLEARCHILDERRLOG" command will clear and 
rearm the error log, and also this status bit. LBRE - LIP Bus Read Error indicates the LIP 
bridge has detected and logged an error on the LIP bus during a read from the LIP bridge 
by the host bus master. The first error that occurs is logged and locked in the LIP bus 
error log. The details of the error can be obtained by issuing the "RLIPERRLOG" 
special function command. Issuing the "CLEAR_LIP_ERRLOG" command will clear 
and rearm the error log, and also this status bit. LB WE - LIP Bus write Error indicates 
the LIP bridge has detected and logged an error on the LIP bus during a write to the LIP 
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bridge by the host bus master. The first error that occurs is logged and locked in the LIP 
bus error log. The details of the error can be obtained by issuing the "R_LIP_ERRLOG" 
special function command. Issuing the "CLEAR_LIP_ERRLOG" command will clear 
and rearm the error log, and also this status bit. ME - Multiple errors bit indicates that the 
LIP bridge has encountered more than one instance of one or more of the error types, and 
so some amount of error history will be available via the "R LIP ERRLOG" and 
"R CHILD ERRLOG" commands. The ME bit will automatically clear when both error 
logs are cleared. 

LIP Bridge Error Logs 

Table 5 illustrates an exemplary structure that is returned in response to the host 
bus master requesting error information for the LIP bus or the child bus. One structure is 
maintained for the LIP bus, and one for the child bus. The log's data bytes are sent in the 
numbered order given below. All fields are cleared by executing the "rearm and clear 
error" command for a given bus. If any logged error fields contain error data (and are 
thus locked against any changes), then a clear operation will rearm them to accumulate 
errors again. The table lists the byte ordering, an abbreviation for the error log field, and 
a description of the data in the field. 



Table 5 



Order 


Name 


Description 


1 


NUMJERR 


Number of errors accumulated following a "rearm and clear error" command for 
a particular bus (child or LIP), or any type of LIP bridge reset 


2 


W_ERR1 


Error code for first latched error associated with a master write operation to the 
bus. 


3 


WJERR1_CA 


Child bus address (if any) associated with first latched write error, or zero if a 
child bus address was not involved. 


4 


W_ERR1_CMD 


Special function command code or child bus "Read Data Tag" associated with 
first latched write error. 


5 


RERR1 


Error code for first latched error associated with a master read operation from 
the bus. 


6 


RJERR1_CA 


Child bus address (if any) associated with first latched read error, or zero if a 
child bus address was not involved. 


7 


RERR1CMD 


Special function command code or child bus "Read Data Tag" associated with 
first latched read error. 


8 


ERR2 


Second latched error code. 


9 


ERR3 


Third latched error code. 
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LIP Bridge Error Codes 

The LIP bus and the LIP bridge's child bus each have a dedicated error log with 
the structure given in Table 5, and error codes in Tables 6 and 7. After the first error is 
stored, that part of the error log is locked from further change and one or more bits are set 
in the "LIP bridge status byte" as appropriate. Following the initial error of a given type 
(read or write) there is space in the error log for two additional errors codes. These are 
used to log an error code if the initial error log entry of a given type (read or write) is full. 
This allows for logging one read and/or one write error plus two more error codes for the 
each bus. When all entries in an error log are filled, subsequent error information will be 
lost. Any error will cause the appropriate bit in the LIP bridge status byte to be set and 
locked. Error data is entirely cleared in a given error log by executing the appropriate 
clear command for the error log. The clear command also rearms the error log to receive 
data again, and clears the appropriate bit (or bits) in the LIP status register. Note that LIP 
bus errors and general LIP bridge errors fall into the numerical range of 0x1-0x80, while 
child bus errors are numbered from 0x80-0xFF. This allows the two types of errors to be 
distinguished in the ERR2 and ERR3 fields of the error log. 



Table 6 
LIP Bus Errors 



NO_ERROR 


0x00 


No Error present 


BADCMD 


0x01 


Command written to LIP bridge did not consist of correct four byte packet Command was 
ignored. 


BAD_READ_CNT 


0x02 


Invalid 'read count' field in a read command packet. The 'read count' field was outside the range 
of 1-15 bytes inclusive. 


BAD_CRC_IN 


0x03 


CRC check failed on incoming command, command was ignored. 


QUEUE_FULL 


0x04 


Input queue full, LIP bridge acknowledged LIP address and then no-acknowledged subsequent 
incoming data bytes. 


RCV_TIMEOUT 


0x05 


Receive timeout. The time between the reception of the LIP address to the reception of the fourth 
command byte exceeded time limit. Command was ignored. 


WATCHDOG_RST 


0x06 


Watch dog reset. An internal error occurred in the LIP bridge which caused the watch dog timer 
to hard reset the LIP bridge. All internal state has been reset, a stop has been issued to the child 
bus, and any commands in process have been lost. 


INTERNAL ERR 


0x07 


Internal error. An unspecified internal error has occurred within the LIP bridge. 


UNREAD.DISC 


0x08 


Unread data discarded. The host bus master read less data from the LIP bridge than it requested in 
the 'read count' field of the command packet and/or failed to read the extra CRC byte, by 
terminating the read transaction early with a no-acknowledge on a data byte from the LIP bridge. 
The remaining data and/or CRC are discarded. 


READOVERRUN 


0x09 


Read overrun error. The host bus master read more data from the LIP bridge than it requested as 
part of a read or special function command. The extra data is returned as random data with a valid 
CRC. 


BROWN.RESET 


OxOA 


Brown Out reset. A drop in supply voltage caused the LIP bridge to reset. 


RSVD_CMD_ERR 


OxOB 


Reserved command error. The host bus master requested execution of a special function 
command with a reserved command code. The command was ignored. 
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DUMPJNCOMP 


OxOC 


RAM Dump incomplete. The LIP bridge was unable to return all 192 bytes of RAM to the host 
bus master following a DUMP_LIP_RAM command. Either the host bus master no- 
acknowledged the data before fully sent, or the transaction took longer than 50mS. 


XMTJTIMEOUT 


OxOD 


Slave transmission timeout. The time elapsed since the host bus master clocked out the first byte 
of data during a LIP bridge read exceeded the bridge slave transmit time-out before the CRC byte 
was clocked out, indicating an incomplete LIP bridge read. 


SNG_RD_CN FLT 


A..AT? 


Single host bus master Read Conflict. A single given host bus master issued two consecutive 
commands to the LIP bridge (and mix of child bus read or special function command prefixed by 
"R_") before reading the data from the first command. 


ML) Li 1 _KU_CIN r Li 1 


n v nr 
UXUr 


Multiple host bus master Read Conflict, host bus masterx issued a child bus read or special 
function command prefixed by "RJ\ and before host bus masterx performed a LIP bridge Read to 
extract the data, host bus mastery issued a child bus read or special function command prefixed by 
"RJ\ 


UNEXPECTED_RD 


0x10 


The LIP bridge received a LIP bridge read when there was no data available for transmission to 
the host bus master. This could occur if the original read request was corrupted or otherwise lost 
or dropped, resulting in no data available for the subsequent LIP bridge read. 




0x11- 
0x80 


Reserved 



Table 7 



Child Bus errors 



CHILD_SCL_SL 


0x81 


PC clock line stuck at logical zero. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILD_SCL_SH 


0x82 


PC clock line stuck at logical one. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILDSDA_SL 


0x83 


PC data line stuck at logical zero. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILD_SDA_SH 


0x84 


PC data line stuck at logical one. This is a hardware fault, or possibly a long 
glitch from a hot plug event. 


CHILDADDRNOACK 


0x85 


No response from PC target (no-acknowledge from address cycle) 


CHILD_DATA_NOACK 


0x86 


Target no-acknowledged data transfer. 


CHILDARBERR 


0x87 


LIP bridge could not obtain access to the child bus from the other LIP bridge. 




0x88-0xff 


Reserved 



CRC Algorithm 

A CRC Algorithm is used to calculate all CRC's within the LIP bridge. It is a 
property of the CRC algorithm that if the last byte processed is the transmitted CRC, then 
the resulting calculated CRC will always be zero if there has been no transmission error. 
Any non-zero value would indicate a transmission error. The algorithm is capable of 
detecting: 1) any odd number of errors anywhere within the packet (i.e. -1,3,5,7... bit 
errors), 2) all double-bit errors anywhere within packet, 3) any cluster of errors that can 
be contained within an 8-bit "window" (1-8 bits incorrect) and 4) most larger clusters of 
errors. 

The CRC calculation can be represented by a linear shift register with feedback 
taps given by the polynomial X 8 + X 5 + X 4 + 1 . This can be implemented in software by a 
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loop construct or a table lookup. The loop implementation produces compact code (about 
20 instructions), but uses about 150 machine cycles to execute. The table implementation 
uses more code space (300 bytes or more) but is much faster (perhaps 10-20 machine 
cycles). Consult "Technical Aspects Of Data Communication, Third Edition, 
5 McNamara" for theory and implementation of several different types of CRC algorithms 
and further references on CRC's in general. 

Exemplary Transactions 

Now that the basic structure of the LIP bridge device and its accompanying 
protocol have been described, the following illustrates some typical transactions between 
10 the host bus master and the LIP bridge. The byte ordering in the packets below is first 
byte to last byte from left to right. Within each byte, the bits are ordered MSB to LSB 
« from left to right. In all of the transaction samples, note that the "acknowledge / no- 

|f acknowledge" bit is provided by the PC interface hardware automatically. In fact, for 

SJ most hardware implementations, it is not possible to modify or prevent the proper use of 

^ 15 this bit. It is shown in the transactions for completeness. 

9* Fig. 1 1 illustrates a host bus master to LIP One Byte Child Bus Write 160 and Table 6 

I illustrates the symbol key for Figs. 1 1 - 16. The host bus master uses this transaction to issue a 

O one-byte write to a target on the child PC bus. This transaction is useful for writing to any PC 

n* target requiring one byte, such as a byte wide PC parallel expander. This transaction will cause 

zb; 20 the following sequence on the child bus: 
□ 1 . Arbitrate for child bus 

2. PC start 

3. Address the PC device on the child bus specified by the child address 

4. Write the data from the data field 
25 5. PC stop 

Note that the child bus is not released by the LIP bridge until the entire transaction is 
complete. The transaction may cause any of the following errors to be logged: 1)LIP 
errors - Bad command, CRC check failed, receive timeout, input queue full and 2) Child 
errors - All 

30 Fig. 12 illustrates a host bus master to LIP Multi-Byte Write 162. The host bus 

master can use this transaction to issue one or more bytes of writes to a target on the child 
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PC bus. Any number of bytes (greater than one) can be sent to a child bus target this 
way, assuming the target device will accept them. This command is useful for child bus 
PC targets requiring more than one byte, such as 16 bit parallel PC expanders, and 
EEPROM devices. 

5 If it is essential for the data to arrive at the PC target on the child bus intact, the 

host bus master can check the LIP status byte after the transmission to insure the 
transaction was error free. Reading back the data sent between data packets will interrupt 
this transaction, and should not be done. This transaction will cause the following 
sequence on the child bus: 
10 1 . Arbitrate for child bus 

2. PC start 

3. Address the PC device on the child bus specified by the child address 

4. Write the data from the data field of subsequent single byte write packets until the CA 
field no longer matches that of the first single byte write packet. 

15 5. PC stop 

Note that the child bus is not released by the LIP bridge until the entire transaction is 
complete. 

The transaction may cause any of the following errors to be logged: 1)LIP errors - 
Bad command, CRC check failed, receive timeout, input queue full, reserved command 
20 error and 2) Child errors - All 

Fig. 13 illustrates a Special Function Action Neither Requiring Nor Returning Data 164. 
The host bus master uses this transaction to invoke a special function action that neither requires 
nor returns data. Execution of commands that perform an action can be verified by reading the LIP 
status byte. The LIP status byte will indicate if there are any errors latched. Some examples of 
25 this command type are: CLEAR_LIP_ERRLOG, CLEAR CHILD_ERRLOG, 

CHILD 12 C_ST ART, CHILD_I2C_STOP, All ENABLE_, DISABLE_ commands, and all 
RESET_ commands. 

The transaction may cause any of the following errors to be logged: 1) LIP errors 
- Bad command, CRC check failed, receive timeout, input queue full, reserved command 
30 error and 2) Child errors - PC bus stuck-at errors. 

Fig. 14 illustrates a Special Function Action Returning Data 166. The host bus 
master uses this transaction to invoke a special function action that returns data. 
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Explicitly verifying execution of these commands is not necessary, since they return data. 
Failure to return data would be the failure indicator, however any errors encountered by 
the LIP bridge are logged. All such commands are prefixed by "R_" in Table 1 . Some 
examples of such a command: RVERSION, RJSTATUS, 
5 R_LST_CHILD_DATA_IDO (returns multiple bytes), RJLIP_ERRLOG, 
R_CHILD_ERRLOG (returns multiple bytes). 

When issuing the special function request, the issuing host bus master identifies 
itself to the LIP bridge via the low bit of the Child Bus address / Special function field. 
This identification is passed through the LIP bridge, and returned to the host bus master 
10 as part of the "Read Data Tag". 

The host bus master should clock out the "Read Data Tag" byte, followed by the 
number of data bytes that the requested special function command provides, plus one 
O CRC byte. The special function will provide one or more bytes of data depending on the 

Js requested command. If the host bus master continues to clock data out past the proper 

J1 15 amount, then each extra data byte returned will be valid CRC for the previous bytes, and 
O a "READ_OVERRUN" error will be logged. Note that the host bus master can check 

y- the "Read Data Tag" field to verify that the data it is receiving was actually intended for 

L, it by checking the "Srcld" bit. Additionally, the "RdCnt" field can be used to further 

S identify the read transaction. If the "NoData" bit is set then there is no data available for 

[fj 20 this read transaction, and the R_LST_CHILD_DATA_IDn command can not be used 
y for recovery. This could be the result of a child bus error. 

The transaction may cause any of the following errors to be logged: LIP errors - 
Bad command, CRC check failed, receive timeout, input queue foil, unread data 
discarded, read overrun, reserved command error 
25 Fig. 15 illustrates a Special Function Action Requiring Data 168. The host bus 

master uses this transaction to invoke a special function action that requires data. This 
capability is provided for possible future use, it is currently not a part of the exemplary 
embodiment. The transaction may cause any of the following errors to be logged: 1) LIP 
errors - 111 formed command, CRC check failed, Receive timeout and 2) special function 
30 errors - Reserved command error 
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Fig. 16 illustrates a host bus master Child Bus Read Via LIP Bridge Action. The 
host bus master should use this transaction to read data from a child bus PC target. Any 
preparation of child bus PC target for a read operation must be done before the child bus 
read is requested. For example, if the child bus PC target is a particular address within 
an EEPROM device, then the appropriate commands for setting the EEPROM address 
must be sent before the read transaction is requested. 

Following transmission of the child bus read request, the host bus master must 
perform a LIP bridge read. The host bus master should clock out the "Read Data Tag" 
byte, followed by the number of data bytes specified in the RdCnt field, plus one CRC 
byte. This can be from three to seventeen bytes inclusive. If the host bus master 
continues to clock data out past the proper amount, then the extra bytes returned will be 
valid CRCs, and a "READ_OVERRUN" error will be logged. Note that the host bus 
master can check the "Read Data Tag" field to verify that the data it is receiving was 
actually intended for it by checking the "Srcld" bit. Additionally, the "RdCnt" field can 
be used to further identify the read transaction. If the "NoData" bit is set then there is no 
data available for this read transaction, and the R_LST_CHILD_DATA_IDn command 
can not be used for recovery. This could be the result of a child bus error. 
This transaction will cause the following sequence on the child bus: 

1. PC start. 

2. Address the PC device on the child bus specified by the child address and request a 
"read" transaction type. 

3. Read data from the child bus PC device until the count specified in the Read Count 
field is reached, or until an error prevents further reading. 

4. PC stop. 

The transaction may cause any of the following errors to be logged: 1) LIP errors 
- Bad command, CRC check failed, receive timeout, input queue full, Unread Data 
Discarded, Read Overrun, bad read count and 2) Child Bus Errors - All. 

LIP Bridge Microcontroller 

The LIP bridge can be implemented using one of several microcontrollers, for 
example, those made by Microchip Technology Inc. There are several devices which are 
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optimal for LIP bridge use. These devices have a hardware I C interface that will 
facilitate excellent performance. Exemplary microcontrollers 180, 182 with their 
associated pin outs are shown in Figs. 17-18. 

Referring to Figs. 19 -21, in connection with Fig. 2, a design overview of some of 
5 the basic firmware required to implement the I 2 C bridge device is shown. Fig. 22, for 
instance shows a flow diagram 190 for the packet handler 191 and associated devices 
which couple between the LIP bus and child bus. Fig. 23 illustrates data flows 192 for 
the packet parser 193 and its associated devices. Fig. 24 illustrates the I 2 C data flows 194 
between the packet handler 195 and child bus 196. 

10 The LIP bridge of the present invention overcomes a shortcoming of I C in an 

environment where there are multiple I C bus masters accessing one or more slave 
targets. In this environment, when two bus masters attempt to read data from the same 
slave target, it is impossible for the slave to know which I C master is performing the 
read operation. There are many instances when this can result in a given I C master 

15 receiving data intended for another I 2 C master, which can cause significant problems. 
The LIP bridge tags all data waiting to be read so that a given I C master can verify that 
the incoming data is intended for it, or if not to discard the data and retry the operation. 

Whenever a LIP bridge device is inserted between an I 2 C master and it's target 
I 2 C device(s), the LIP bridge device provides fault detection and isolation capabilities 

20 that result in a solution with greater reliability. For example, consider two designs: 

A. I 2 C master connected to 64 target I 2 C devices which monitor eight equipment bays. 

B. I 2 C master connected to 8 LIP bridge devices (one per equipment bay), with each LIP 
bridge connected the eight target I 2 C devices in an equipment bay. 

Consider any of the following common faults that could occur: 

25 1 . Target I C device fails, and renders I C bus unusable. 

2. An electrical connector, wiring, or power fault in an equipment bay causes bay failure 
and renders the child side I 2 C bus unusable. 

3. The equipment is exposed to electrical interference, causing corruption of data 
flowing to and from the I 2 C master. 

30 If faults one or two occurred, design "A" would completely fail, while design "B" 

could continue to function at a reduced capacity due to the ability to detect then isolate 
the failure behind a LIP bridge device. If fault three occurred, design "A" would 
completely fail, while design "B" would continue to operate by making use of the data 
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integrity checking. If data integrity checks were frequently failing, the equipment's 
operator could be notified to rectify the problem. 

To provide a high availability solution, each LIP bridge device has hardware and 
firmware features that allow it to self-monitor it's own operation and take corrective 
action when possible or at least report potential problems. In addition, availability is 
greatly enhanced with the ability to partner a LIP bridge device with a second LIP bridge 
device to serve the same master and set of target I 2 C devices. Partnering LIP bridges 
provides redundancy in case of LIP bridge failure, and takes advantage of partnering 
signals so that each LIP bridge device can reset or disable the other LIP bridge device to 
isolate it in case of failure. Partnering additionally allows the host to cross check data 
provided by the partner LIP bridge, as a technique to virtually guarantee data integrity. 

The LIP bridge device invention solves several problems inherent in the use of 
I 2 C busses. The device: 

1 . Expands the number of I 2 C addresses available on a single level I 2 C bus by a factor of 
128. Cascading LIP bridges into multilevel busses expands available addresses by 
128*128. 

2. Provides data integrity checking, data transmission reliability, and correct recipient 
guarantee. 

3. Identifies data during read operations so that the requester can verify it is receiving 
the correct data. 

4. Provides high availability and fault detection and isolation. 

5. Provides the ability to partner LIP bridges to add hardware redundancy for extremely 
high availability and confidence in data integrity. 

For many computer systems (including PC's and especially servers), 
communication/network equipment (switches, routers, etc), office machines, and 
industrial machines - the customer values the equipment's ability to monitor and report 
faults or be managed and controlled remotely even if the equipment is unattended or even 
locked away. Designers must provide an inexpensive method of supplying these 
competitive features that ensures data integrity and is itself a reliable component. The 
invention meets these goals by allowing the use of inexpensive I C devices to provide 
monitoring and control functions over a single cost effective I 2 C bus, while achieving 
high availability and guaranteed data integrity. 
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In addition, the use of I C which uses a serial clock an data line as a transmission 
medium is not required, and this technology could be implemented on another 
information bus such as RS232, RS485, SPI, etc. An illustration of such an arrangement 
is shown in Fig. 22. Fig. 22 shows an RS232/RS485 bus master 210 which couples to an 
appropriate RS232/RS485 LIP bridge 212 through a LIP serial bus 214 carrying LIP 
protocol over an RS232 or RS485 electrical medium rather than I 2 C. RS485 and RS422 
in particular, can be used over longer distances, compared to I C. Target devices 216 are 
coupled to the bridge device 212 over an I 2 C bus 218 in the manner previously described. 

The foregoing description merely illustrates the principles of the invention. It will 
thus be appreciated that those skilled in the art will be able to devise various 
arrangements, which, although not explicitly described or shown herein, embody the 
principles of the invention, and are included within its spirit and scope. For example in 
certain high precision, low fault tolerant applications, the host bus master performs every 
child bus read operation on two different LIP bridges to ensure data integrity of the LIP 
bridge. Also, a LIP bridge can include more than one parent bus or child bus ports. 
Multiple child busses can allow greater economy with a reduction in redundancy - for 
instance, the accessing of more I 2 C addresses per dollar. In addition, multiple parent 
busses utilized with one child bus allow the bridging of two systems together while 
providing all the benefits of an individual bridge. An example of such an application is 
remote management capability by two servers of a large disk drive rack. Furthermore, all 
examples and conditional language recited are principally intended expressly to be only 
for instructive purposes to aid the reader in understanding the principles of the invention 
and the concepts contributed by the inventor to furthering the art, and are to be construed 
as being without limitation to such specifically recited examples and conditions. 
Moreover, all statements herein reciting principles, aspects, and embodiments of the 
invention, as well as specific examples thereof, are intended to encompass both structural 
and functional equivalents thereof. Additionally, it is intended that such equivalents 
include both currently known equivalents as well as equivalents developed in the future, 
i.e., any elements developed that perform the same function, regardless of structure. 

In the claims hereof any element expressed as a means for performing a specified 
function is intended to encompass any way of performing that function including, for 
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example, a) a combination of circuit elements which performs that function or b) 
software in any form, including, therefore, firmware, microcode or the like, combined 
with appropriate circuitry for executing that software to perform the function. The 
invention as defined by such claims resides in the fact that the functionalities provided by 

5 the various recited means are combined and brought together in the manner which the 
claims call for. Applicant thus regards any means which can provide those functionalities 
as equivalent as those shown herein. Many other modifications and applications of the 
principles of the invention will be apparent to those skilled in the art and are 
contemplated by the teachings herein. Accordingly, the scope of the invention is limited 

10 only by the claims. 
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